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[57] ABSTRACT 

A market making node in a network routes machine readable 
documents to connect businesses with customers, suppliers 
and trading partners. The self defining electronic documents, 
such as XML based documents, can be easily understood 
amongst the partners. Definitions of these electronic busi- 
ness documents, called business interface definitions, are 
posted on the Internet, or otherwise communicated to mem- 
bers of the network. The business interface definitions tell 
potential trading partners the services the company offers 
and the documents to use when communicating with such 
services. Thus, a typical business interface definition allows 
a customer to place an order by submitting a purchase order 
or a supplier checks availability by downloading an inven- 
tory status report. Also, the registration at a market maker 
node of a specification of the input and output documents, 
coupled with interpretation information in a common busi- 
ness library, enables participants in a trading partner network 
to execute the transaction in a way which closely parallels 
the way in which paper based businesses operate. 
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Abstract Text -ABTX(1): 

A market making node in a network routes machine readable documents to 
connect businesses with customers, suppliers and trading partners. The self 
defining electronic documents, such as XML based documents, can be easily 
understood amongst the partners. Definitions of these electronic business 
documents, called business interface definitions, are posted on the Internet. 
or othenwise communicated to members of the network. The business interface 
definitions tell potential trading partners the services the company offers and 
the documents to use when communicating with such services. Thus, a typical 
business interface definition allows a customer to place an order by submitting 
a purchase order or a supplier checks availability by downloading an inventory 
status report. Also, the registration at a market maker node of a 
specification of the Input and output documents, coupled with interpretation 
information in a common business library, enables participants in a trading 
partner network to execute the transaction in a way which closely parallels the 
way in which paper based businesses operate. 

Application Filing Date - AD (1): 
19981016 

Brief Summary Text - BSTX (7): 

The Internet and other communications networks provide avenues for 
communication among people and computer platfonms which are being used for a 
wide variety of transactions, including commercial transactions in which 
participants buy and sell goods and services. Many efforts are underway to 
facilitate commercial transactions on the Internet . However, with many 
competing standards, in order to execute a transaction, the parties to the 
transaction must agree in advance on the protocols to be utilized, and often 
require custom integration of the platfomi architectures to support such 
transactions. Commercial processes internal to a particular node not 
compatible with agreed upon standards, may require substantial rework for 
integration with other nodes. Furthermore, as a company commits to one 
standard or the other, the company becomes locked-in to a given standardized 
group of transacting parties, to the exclusion of others. 

Brief Summary Text - BSTX (8): 

A good overview of the challenges met by Internet commerce development is 
provided in Tenenbaum, et al., "Eco System: An Internet Commerce Architecture", 
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Computer, May 1997, pp. 48-55. 



Brief Summary Text - BSTX (9): 

To open commercial transactions on the Internet, standardization of 
architectural frameworks is desired. Platforms developed to support such 
commercial frameworks include IBM Commerce Point, Microsoft Internet Commerce 
Framework, Netscape ONE (Open Network Environment), Oracle NCA (Network 
Computing Architecture), and Sun/JAVASoft JECF (JAVA Electronic Commerce 
Framework). 

Brief Summary Text - BSTX (10): 

In addition to these proprietary frameworks, programming techniques, such as 
common distributed object model based on CORBA NOP (Common Object Request 
Broker Architecture Internet ORB Protocol), are being pursued. Use of the 
common distributed object model is intended to simplify the migration of 
enterprise systems to systems which can inter-operate at the business 
application level for electronic commerce. However, a consumer or business 
using one framework is unable to execute transactions on a different framework. 
This limits the growth of electronic commerce systems. 

Brief Summary Text - BSTX (15): 

The present invention offers an infrastructure for connecting businesses 
with customers, suppliers and trading partners. Under the infrastructure of 
the present invention, companies exchange information and services using 
self-defining, machine-readable documents, such as XML (Extensible Markup 
Language) based documents, that can be easily understood amongst the partners. 
Documents which describe the documents to be exchanged, called business 
interface definitions BIDs herein, are posted on the Internet or othenA/ise 
communicated to members of the network. The business interface definitions 
tell potential trading partners the services the company offers and the 
documents to use when communicating with such services. Thus, a typical 
business interface definition allows a customer to place an order by submitting 
a purchase order compliant with a document definition published in the BID of 
a party to receive the purchase order . A supplier is allowed to check 
availability by downloading an inventory status report compliant with a 
document definition published in the BID of a business system managing 
inventory data. Use of predefined, machine-readable business documents 
provides a more intuitive and flexible way to access enterprise applications. 

Brief Summary Text - BSTX (26): 

According to another aspect of the invention, the specification of the input 
and output documents includes interpretation information for at least one of 
the sets of storage units identified by the logical structure. The 
interpretation information in one example encodes definitions for sets of 
parsed characters. In another example, the interpretation information provides 
for content model specifications, such as requiring a specific logic stnjcture 
to carry a member of a list of codes mapped to product descriptions in a 
catalog . In some systems, the storage units in a logic stmcture of a document 
may include sets of unparsed data, as suits the needs of a particular 
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implementation. 

Brief Summary Text - BSTX (41 ): 

The whole process of building business interface definitions and enabling 
servers to manage commerce according to such descriptions is facilitated by a 
common business library, or repository, of information models for generic 
business concepts including business description primitives like companies, 
services and products, business forms like catalogs, purchase orders and 
invoices, and standard measurements. Including time and date, location and 
classification of goods. 

Detailed Description Text - DETX (2): 

A detailed description of the present invention is provided with respect to 
the figures, in which FIG. 1 illustrates a network of market participants and 
market makers based on the use of business interface definitions, and 
supporting the trading of input and output documents specified according to 
such interface descriptions. The network includes a plurality of nodes 11-18 
which are interconnected through a communication network such as the Internet 
19, or other telecommunications or data communications network. Each of the 
nodes 11-19 consists of a computer, such as a portable computer, a desktop 
personal computer, a workstation, a network of systems, or other data 
processing resources. The nodes include memory for storing the business 
interface definition, processors that execute transaction processes supporting 
commercial transactions with other nodes in the network, and computer programs 
which are executed by the processors in support of such services. In addition 
each of the nodes includes a network interface for providing for communication 
across the Internet 19, or the other communication network. 

Detailed Description Text - DETX (5): 

In this example, the market participant 18 is connected directly to the 
market maker 17, rather than through the Internet 19. This connection directly 
to the market maker illustrates that the configuration of the networks 
supporting commercial transactions can be very diverse, incorporating public 
networks such as the Internet 19, and private connections such as a local area 
network or a Point-to-Point connection as illustrated between nodes 17 and 18. 
Actual communication networks are quite diverse and suitable for use to 
establish commercial transaction networks according to the present invention. 

Detailed Description Text - DETX (8): 

Thus in an exemplary system, participant nodes in the network establish 
virtual enterprises by interconnecting business systems and services with XML 
encoded documents that businesses accept and generate. For example, the 
business interface definition of a particular service establishes that if a 
document matching the BID of a request for a catalog entry is received, then a 
document matching a BID of a catalog entry will be returned. Also, if a 
document matching the BID of a purchase order is received, and it is acceptable 
to the receiving terminal, a document matching the BID of an invoice will be 
returned. The nodes in the network process the XML documents before they enter 
the local business system, which is established according to the variant 
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transaction processing architecture of any given system in the network. Thus, 
the system unpacks sets of related documents, such as MIME-encoded sets of XML 
documents, parses them to create a stream of "mark-up messages". The messages 
are routed to the appropriate applications and services using for example an 
event listener model like that described below. 

Detailed Description Text - DETX (9): 

The documents exchanged between business services are encoded using an XML 
language built from a repository of building blocks (a common business 
language) from which more complex document definitions may be created. The 
repository stores modules of interpretation information that are focused on the 
functions and information common to business domains, including business 
description primitives like companies, sen/ices and products; business forms 
like catalogs, purchase orders and invoices; standard measurements, like time, 
date, location; classification codes and the like providing interpretation 
information for logical structures in the XML documents. 

Detailed Description Text - DETX (13): 

The service type element above illustrates interpretation information 
carried by a business interface definition, in this example a content form 
allowing identification of any one of a list of valid service types. Other 
interpretation information includes data typing, such as for example the 
element <H3> Internet Address </H3> including the content form 
"uri" and expressed in the data type "string." Yet other interpretation 
information includes mapping of codes to elements of a list, such as for 
example the element <H3> State </H3> including the code mapping for 
states in the file "COUNTRY.US.SUBENTITY." 

Detailed Description Text - DETX (21): 

The parser 301 takes a purchase order like that in the example above, or 
other document, specified according to the business interface definition and 
creates a set of events that are recognized by the local transaction processing 
architecture, such as a set of JAVA events for a JAVA virtual machine. 

Detailed Description Text - DETX (23): 

For example, the purchase order specified above may be monitored by programs 
listening for events generated by the parser, which would connect the document 
or its contents to an order entry program. Receipt of product descriptions 
within the purchase order might invoke a program to check inventory. Receipt 
of address information within the purchase order, would then invoke a program 
to check availability of services for delivery. Buyer information fields in 
the document, could invoke processes to check order history for credit 
worthiness or to offer a promotion or similar processing based on knowing the 
identity of the consumer. 

Detailed Description Text - DETX (24): 

Complex listeners can be created as configurations of primitive ones. For 
example, a purchase order listener may contain and invoke the list listeners 
set out in the previous paragraph, or the list members may be invoked on their 
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own. Note that the applications that the listeners run are unlikely to be 
native XML processes or native JAVA processes. In these cases, the objects 
would be transformed into the format required by the receiving trans 
application. When the application finishes processing, its output is then 
transfomned back to the XML format for communication to other nodes in the 
network. 

Detailed Description Text - DETX (39): 

&lt: PURCHASES HTML="OL"><ITEM HTML="LI"><NAME 
HTML="B">STUFF</NAME><PRICE 
HTML="B"&gt:123</PRICE></ITEM></PURCHASES> 

Detailed Description Text - DETX (52): 

FIG. 8 is a heuristic diagram showing logical structures stored in the 
repository in the business interface definition builder 700. Thus, the 
repository storage representative party business interface definitions 800, 
including for example a consumer BID 801. a catalog house BID 802, a warehouse 
BID 803, and an auction house BID 804. Thus, a new participant in an online 
market may select as a basic interface description one of the standardized BIDs 
which best matches its business. In addition, the repository will store a set 
of service business interface definitions 805. For example, an order entry BID 
806, an order tracking BID 807, an order fulfillment BID 808, and a catalog 
service BID 809 could be stored. As a new participant in the market builds a 
business interface definition, it may select the business interface definitions 
of standardized services stored in the repository. 

Detailed Description Text - DETX (53): 
In addition to the party and service BIDs, input and output document BIDs 
are stored in the repository as indicated by the field 810. Thus, a purchase 
order BID 81 1 . an invoice BID 812, a request for quote BID 813, a product 
availability report BID 814, and an order status BID 815 might be stored in the 
repository. 

Detailed Description Text - DETX (59): 

This XML fragment defines a service consisting of two transactions, one for 
taking orders and the other for tracking them. Each definition expresses a 
contract or promise to carry out a service if a valid request is submitted to 
the specified Web address. The Order service here requires an input document 
that conforms to a standard "po.dtd" Document Type Definition located in the 
repository, which may be local, or stored in an industry wide registry on the 
network. If a node can fulfill the order, it will return a document conforming 
to a customized "invoice.dtd" whose definition is local. In effect, the 
company is promising to do business with anyone who can submit a Purchase Order 
that conforms to the XML specification it declares. No prior arrangement is 
necessary. 

Detailed Description Text - DETX (60): 

The DTD is the fomnal specification or grammar for documents of a given 
type; it describes the elements, their attributes, and the order in which they 
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must appear For example, purchase orders typically contain the names and 
addresses of the buyer and seller, a set of product descriptions, and 
associated terms and conditions such as price and delivery dates. In 
Electronic Data Interchange EDI for example, the X12 850 specification is a 
commonly used model for purchase orders . 

Detailed Description Text - DETX (64): 
business forms like catalogs, purchase orders, and invoices; 

Detailed Description Text - DETX (66): 

This information is represented as an extensible, public set of XML building 
blocks that companies can customize and assemble to develop XML applications 
quickly. Atomic CBL elements implement industry messaging standards and 
conventions such as standard ISO codes for countries, currencies, addresses, 
and time. Low level CBL semantics have also come from analysis of proposed 
metadata frameworks for Internet resources, such as Dublin Core. 

Detailed Description Text - DETX (67): 

The next level of elements use these building blocks to implement the basic 
business forms such as those used in X12 EDI transactions as well as those used 
in emerging Internet standards such as OTP (Open Trading Protocol) and OBI 
(Open Buying on the Internet ). 

Detailed Description Text - DETX (68): 

CBUs focus is on the functions and information that are common to all 
business domains (business description primitives like companies, services, and 
products; business fomis like catalogs, purchase orders, and invoices; standard 
measurements, date and time, location, classification codes). CBL builds on 
standards or industry conventions for semantics where possible (e.g., the rules 
that specify "day/month/year" in Europe vs "month/day/year" in the U.S. are 
encoded in separate CBL modules). 

Detailed Description Text - DETX (75): 
In FIG. 10, an Airbill 1000 is being defined by customizing a generic 
purchase order DTD 1001, adding more specific information about shipping weight 
1002. The generic purchase order 1001 was initially assembled from the ground 
up out of CBL modules for address, date and time, currency, and vendor and 
product description. Using CBL thus significantly speeds the development and 
implementation of XML commerce applications. More importantly, CBL makes it 
easier for commercial applications to be interconnected. 

Detailed Description Text - DETX (82): 

The role of CBL and the BID processor of the present invention in an 
XML/JAVA environment can be further understood by the following explanation of 
the processing of a Purchase Order . 

Detailed Description Text - DETX (83): 

Company A defines its Purchase Order document type using a visual 
programming environment that contains a library of CBL DTDs and modules, all 
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defined using common business language elements so that they contain data type 
and other interpretation information. Company A's PO might just involve minor 
customizatlons to a more generic "transaction document" specification that 
comes with the CBL library, or it might be built from the ground up from CBL 
modules for address, date and time, currency, etc. 

Detailed Description Text - DETX (85): 

A compiler takes the purchase order definition and generates several 
different target forms. All of these target forms can be derived through "tree 
to tree" transfomiations of the original specification. The most important for 
this example are: 

Detailed Description Text - DETX (86): 

(a) the XML DTD for the purchase order . 

Detailed Description Text - DETX (87): 

(b) a JAVA Bean that encapsulates the data structures for a purchase order 
(the JAVA classes, arguments, datatypes, methods, and exception structures are 
created that correspond to information in the Schema definition of the purchase 
order) . 

Detailed Description Text - DETX (88): 

(c) A "marshaling" program that converts purchase orders that confonn to the 
Purchase Order DTD into a Purchase Order JAVA Bean or loads them Into a 
database, or creates HTML (or an XSL style sheet) for displaying purchase 
orders in a browser. 

Detailed Description Text - DETX (89): 

(d) An "unmarshaling" program that extracts the data values from Purchase 
Order JAVA Beans and converts them into an XML document that conforms to the 
Purchase Order DTD. 

Detailed Description Text - DETX (90): 

Now, back to the scenario. A purchasing application generates a Purchase 
Order that conforms to the DTD specified as the service interface for a 
supplier who accepts purchase orders . 

Detailed Description Text - DETX (91): 

The parser uses the purchase order DTD to decompose the purchase order 
instance into a stream of information about the elements and attribute values 
it contains. These "property sets" are then transformed into corresponding 
JAVA event objects by wrapping them with JAVA code. This transformation in 
effect treats the pieces of marked-up XML document as instmctions in a custom 
programming language whose grammar is defined by the DTD. These JAVA events 
can now be processed by the marshaling applications generated by the compiler 
to "load" JAVA Bean data structures. 

Detailed Description Text - DETX (95): 

For the example purchase order here, there might be listeners for: 
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Detailed Description Text - DETX (96): 

the purchase order, which would connect it to an order entry program, 
Detailed Description Text - DETX (100): 

Complex listeners can be created as configurations of primitive ones (e.g., 
a purchase order listener may contain and invoke these listeners here, or they 
may be invoked on their own). 

Detailed Description Text - DETX (103): 

The market maker is a server that binds together a set of internal and 
external business services to create a virtual enterprise or trading community. 
The server parses incoming documents and invokes the appropriate services by. 
for example, handing off a request for product data to a catalog server or 
foHA/arding a purchase order to an ERP system. The server also handles 
translation tasks, mapping the information from a company's XML documents onto 
document fomnats used by trading partners and into data formats required by its 
legacy systems. 

Detailed Description Text - DETX (104): 

With respect to the service definition above, when a company submits a 
purchase order, the XML parser in the server uses the purchase order DTD to 
transform the purchase order instance into a stream of infomiation events. 
These events are then routed to any application that is programmed to handle 
events of a given type; in some cases, the information is forwarded over the 
Internet to a different business entirely. In the purchase order example, 
several applications may act on information coming from the parser 

Detailed Description Text - DETX (105): 

An order entry program processes the purchase order as a complete message; 
Detailed Description Text - DETX (106): 

An ERP system checks inventory for the products described in the purchase 
order : 

Detailed Description Text - DETX (1 14): 
FIG. 15 illustrates the processor, components and sequence of processing of 
incoming data at market maker node according to the present invention. The 
market maker node includes a communication agent 1500 at the network interface 
The communication agent is coupled with an XML parser 1501 which supplies 
events to an XML processor 1502. The XML processor supplies events to a 
document router. The document router feeds a document service 1504 that 
provides an interface for supplying the received documents to the enterprise 
solution software 1505 in the host system. The communication agent 1500 is an 
internet interface which includes appropriate protocol stacks supporting such 
protocols as HTTP, SMTP, FTP. or other protocols. Thus, the incoming data 
could come in an XML syntax, an ASCII data syntax or other syntax as suits a 
particular communication channel. All the documents received in non-XML 
syntaxes are translated into XML and passed the XML parser. A translation 



2/27/05, EAST Version: 2.0.1.4 



r 



table 1506 is used to support the translation from non-XML form into XML form. 

Detailed Description Text - DETX (120): 

"if you send me a request for a catalog. I will send you a catalog : 
Detailed Description Text - DETX (121): 

"if you send me a purchase order and I can accept it, I will send you an 
invoice". 

Detailed Description Paragraph Table - DETL (2): 

<DTD NAME="markpart.dtd"&gt: <H2> Market Participant&lt:/H2> 
&lt:H3&gt:Market Participant</H3> <ELEMENTTYPE 
NAME="market.participant"> &lt:EXPLAIN><TITLE> A Market 
Particlpant</TITLE> <SYNOPSIS&gt:A business or person and its service 
interfaces.</SYNOPSIS> <P>A market participant is a document 
definition that is created to describe a business and at least one person 
with an email address and it presents a set of pointers to service interfaces 
located on the network. In this example the pointers have been resolved and 
the complete BID is presented here.</P>/EXPLAIN> 

<MODEL><CHOICE> <ELEMENT NAME="business"></ELEMENT> 
<ELEMENT NAME="person"&gt:</ELEMENT> 
</CHOICE&gt:</MODEL>&lt:/ELEMENTTYPE> <H3&gt:Party 
Prototype</H3> <PROTOTYPE NAME="party"> 
<EXPLAIN><TITLE>The Party Prototype</TITLE></EXPLAIN> 
<MODEL><SEQUENCE> <ELEMENT 
NAME="party.name"OCCURS="+"></ELEMENT> &lt:ELEMENT 
NAME="address.set">&lt:/ELEMENT> </SEQUENCE></MODEL&gt: 
</PROTOTYPE> <H3> Party Types</H3> <ELEMENTTYPE 
NAME="business"> <EXPLAIN><TITLE>A Business</TITLE> 
<SYNOPSIS>A business (party) with a business number 
attribute.</SYNOPSIS&gt: &lt:P>This element Inherits the content model 
of the party prototype and adds a business number attribute, which serves as 
a key for database lookup. The business number may be used as a cross- 
reference to/from customer id, credit limits contacts lists, 
etc.&lt:/P></EXPLAIN> <EXTENDS HREF="party"> <ATTDEF 
NAME="business.number"></REQUIRED></REQUIRED></ATTDBF> 
</EXTENDS> </ELEMENTTYPE> <H3>Person Name</H3&gt: 
<ELEMENTTYPE NAME="person"> &lt:EXPLAIN><TITLE>A 
Person</TITLE>/EXPLAIN&gt: <EXTENDS HREF="party"> <ATTDEF 
NAME="SSN"><IMPLIED>&lt:/IMPLIED&gt:&lt:/ATTDEF> &lt:/EXTENDS> 
</ELEMENTTYPE> &lt:H3>Party Name</H3> <ELEMENTTYPE 
NAME="party.name"> <EXPLAIN><TITLE&gt:A Party's Name</TITLE> 
<SYNOPSIS>A party's name in a string of 
character.</SYNOPSIS></EXPLAIN> 

<MODEL>&lt:STRING></STRING></MODEL&gt: </ELEMENTTYPE> 
<H3>Address Set</H3> <ELEMENTTYPE NAME="address.set"> 
<MODEL><SEQUENCE> <ELEMENT 
NAME="address.physical''></ELEMENT> <ELEMENT 
NAME="telephone"OCCURS="*"&gt:&lt:/ELEMENT> &lt:ELEMENT 
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NAME="fax"OCCURS="*">&lt:/ELEMENT> <ELEMENT 
NAME="email"OCCURS="*"></ELEMENT> <ELEMENT 

NAME="internet"OCCURS="*"></ELEMENT> </SEQUENCE>&lt:/MODEL&gf 
</ELEMENTTYPE> <H3> Physical Address</H3&gt: <ELEMENTTYPE 
NAME="address.physical"> <EXPLAIN><TITLE>Physical 
Address</TITLE> <SYNOPSIS&gt:The street address, city, state, and zip 
code.</SYNOPSIS></EXPLA IN> <MODEL><SEQUENCE> 
&lt:ELEMENT NAIVIE="street"></ELEMENT> <ELEMENT 
NAME="city">&it;/ELEMENT> <ELEMENT NAME="state"&gt:</ELEIVIENT> 
<ELEMENTNAME="postcode"OCCURS="?"></ELEMENT&gt: &lt:ELEMENT 
NAIVIE="country"></ELEMENT> </SEQUENCE></IV10DEL&gt: 
</ELEMENTTYPE> <H3>Street</H3> <ELEMENTTYPE 
NAME="street"&gt: <EXPLAIN><TITLE&gt:Street Address</TITLE> 
<SYNOPSIS>Street or postal address.&lt:/SYNOPSIS></EXPLAIN> 
<MODEL><STRING></STRING&gt:</MODEL> </ELEMENTTYPE> 
<H3>City</H3> <ELEMENTTYPE NAME="city"> 
&lt:EXPI_AIN>&lt:TITLE>City Name or Code<n"ITLE> <P>The city 
name or code is a string that contains sufficient information to Identity a 
city within a designated state.</P> </EXPLAIN> 

<MODEL&gt:<STRING></STRING></MODEL> </ELEMENTTYPE&gt: 
&lt:H3>State&lt:/H3> &lt:ELEMENTTYPE NAME="state"> 
&lt:EXPLAIN><TITLE>State, Province or Prefecture Name or 
Code</TITLE> <P>The state name or code contains sufficient 
information to identfy a state within a designated 
country.&lt:/P></EXPLAIN> <MODEL><STRING 
DATATYPE="COUNTRY.US.SUBENTITY"&gt:&lt:/STRING></MODEL&gt: 
</ELEMENTTYPE> <H3>Postal Code</H3> <ELEMENTTYPE 
NAME="postcode"> <EXPI_AIN><TITLE>Postal Code<n"ITLE> 
<P>A postal code is an alphanumeric code, designated by an appropriate 
postal authority, that is used to identfy a location or region within the 
jurisdiction of that postal authority. Postal authorities include designated 
national postal authorities.</P></EXPLAIN> <MODEL><STRING 
DATATYPE="string"></STRING></MODEL&gt: &lt:/ELEMENTTYPE> 
<H3>Country</H3> <ELEMENTTYPE NAME="country"> 
&lt:EXPLAIN><TITLE>Country Code</TITLE> <P>A country code 
is a two-letter code, designated by ISO, that is used to uniquely identfy a 
country.</P>/EXPLAIN> <MODEL><STRING 
DATATYPE="country"></STRING></MODEL> </ELEMENTTYPE> 
<H3>Network Addresses</H3> <ELEMENTTYPE NAME="telephone"&gt- 
&lt:EXPLAIN><TITLE&gt:Telephone Number&lt:TITLE> &lt:P&gt:A telephone 
number is a string of alphanumerics and punctuation that uniquely Identifies a 
telephone service terminal, including extension 
number.<P&gt:</EXPI_AIN&gt: 

<MODEL&gt:<STRING&gt:</STRING>&lt:/MODEL> </ELEMENTTYPE> 
<H3>Fax</H3> <ELEMENTTYPE NAME="fax"> 
&lt:EXPLAIN&gt:<TITLE&gt:Fax Number</TITLE&gt: <P>A fax number is 
a string of alphanumerics and punctuation that uniquely identifies a fax 
service termlnal.</P> </EXPLAIN> 

<MODEL>&lt:STRING>&lt:/STRING>&lt:/MODEL> &lt:/ELEMENTTYPE&gt: 
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<H3>Email</H3> <ELEMENTTYPE NAME="email"> 
<EXPLAIN>&lt:TITLE>Email Address</TITLE> <P>An email 
address is a datatype-constrained string that uniquely identifies a mailbox on 
a server.</P></EXPLAIN> <MODEL&gt:<STRING 
DATATYPE="email"></STRING></MODEL> </ELEMENTTYPE&gf 
<H3>internet Address</H3> <ELEMENTTYPE NAME=" internet "&at-' 
<EXPLAIN><TITLE>liiternetAddress</TITLE> <P>An 
Internet address is a datatype-constrained string that uniquely identifies a 
resource on the Internet by means of a URL.</P></EXPLAIN> 

<MODEL><STRINGDATATYPE="url"></STRING>&lt:/MODEL&gf 
</ELEMENTTYPE> </DTD> </SCHEMA> Service Description Sample 
&lt:!DOCTYPE schema SYSTEM "bidl.dtd"&gt: <SCHEMA> <H1> Service 
Description Sample BID&lt:/H1> <META WHO.OWNS="Veo Systems" 

WHO.COPYRIGHT='Veo Systems" WHEN.COPYRIGHT="1998" DESCRIPTION="Sample 

BID" 

WHO.CREATED="*" WHEN.CREATED="*" WHAT.VERSION="*" WHO MODIFIED="*" 
WHEN.MODIFIED="*" WHEN.EFFECTIVE="*" WHEN.EXPIRES="*" WHO EFFECTIVE="*" 
WHO.EXPIRES="*"> </META> &lt:PROLOG> <XMLDECL 
STANDALONE="no"></XMLDECL&gt: &lt:DOCTYPE NAME="service"&gf 
<SYSTEM>service.dtd</SYSTEM></DOCTYPE> &lt PROLOG&qf 
<DTD NAME="service.dtd"> <H2&gt:Services&lt:/H2&gt: 
<H3&gt:lncludes</H3> <!~ 

INCLUDE><SYSTEM>comments.bim</SYSTEM></INCLUDE~&gf 
<H3>Service Set</H3> <ELEMENTTYPE NAME="service set"&gf 
<EXPLAIN><TITLE>Service Set&lti/TITLE> <SYNOPSIS&gt A set of 
servlces.</SYNOPSIS>&lt:/EXPLAIN&gt: <MODEL> <ELEMENT 
NAME="service"OCCURS="+"></ELEMENT> 

</MODEL>&it;/ELEMENTTYPE> <H3>Services Prototype&lf/H3&qt- 
<PROTOTYPE NAME="prototype.service"> 

<EXPLAIN&gt:<TITLE>Service</TITLE></EXPLAIN&gf 
<MODEL><SEQUENCE> <ELEMENT 
NAME="sen/ice.name"></ELEMENT> <ELEMENT 
NAME="service.terms"OCCURS="+"></ELEMENT> <ELEMENT 
NAME="service.location"OCCLRS="+"></ELEMENT> &lt:ELEMENT 
NAME="service.operation"OCCLRS="+">&lt:/ELEMENT> 
<SEQUENCE></MODEL> <!- ATTGROUP><IMPLEMENTS 
HREF="common.atrrib"></IMPLEMENTS>&lt:/ATTGROUP &lt:/PROTOTYPE&qf 
<H3>Service</H3> <INTRO>&lt:P>A service is an addressable 
network resource that provides interfaces to specific operations by way of 
input and output documents.</P></INTRO> <ELEMENTTYPE 
NAME="service"> <EXPLAIN><TITLE>Service</TITLE> 
<P>A service is defined in temris of its name, the location(s) at which 
the service is available, and the operation(s) that the service 

performs.&lt:/P></EXPLAIN&gt: &lt:MODEL&gt:<SEQUENCE&gt: &lt:ELEMENT 
NAME="service.name"></ELEMENT> <ELEMENT 
NAME="service.location"></ELEMENT> <ELEMENT 
MAJ1^""®®^'^°P®''^*'°""^^^^'^S=""'"&9t:&lt:/ELEMENT> <ELEMENT 

&lt:/SEQUENCE></MODEL&gt: 
</ELEMENTTYPE&gt: &lt:H3&gt:Service Name&lt:/H3&gt: &lt:ELEMENTTYPE 
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NAME="service.name"> &lt:EXPLAIN>&lt:TITLE>Service Name<n-|TLE> 
<P>The service name is a human-readable string that ascribes a moniker 
for a service. It may be employed is user Interfaces and documentation or for 
other purposes.</P></EXPI_AIN> 

<MODEL>&lt:STRING&gt:&it:/STRING></MODEL> &lt:/ELEMENTTYPE&af 
<H3>Service Location</H3> <ELEMENTTYPE ' 
NAME="service.locatlon"> <EXPLAIN><TITLE>Service 
Locatlon</TITLE&gt: <SYNOPSIS>A LRI of a service.</SYNOPSIS> 
<P&gt:A service location is a datatype-constrained string that locates a 
service on the Internet by means of a URI.</P></EXPLAIN&gf 

M;MODEL><STRINGDATATYPE="uri"></STRING>&lt:/MODEL&qt- 
</ELEMENTTYPE> <H3&gt:Service Operations</H3> 
&lt:INTRO><P>A service operation consists of a name, location and its 
interface, as identified by the type of input document that the service 
operation accepts and by the type of document that it will return as a 
result.&lt:/P></INTRO> <ELEMENTTYPE NAME="service.operation"&gf 
<EXPLAIN><TITLE>Service Operations</riTLE> <P>A 
service operation must have a name, a location, and at least one document type 
as an input, with one or more possible document types returned as a result of 
the operation.</P> </EXPLAIN> <MODEL><SEQUENCE> 
<ELEMENTNAME="service.operation.name"></ELEMENT> &lt ELEMENT 
NAME="service.operation.location"></ELEMENT&gt: &lt:ELEMENT 
NAME="service.operation.input"></ELEMENT> &lt:ELEMENT 
NAME="service.operation.output"></ELEMENT&gf 

</SEQUENCE&gt:&lt:/MODEL&gt: &lt:/ELEMENTTYPE> &lt:H3>Service 
Operation Name</H3&gt: <ELEMENTTYPE NAME="service.operation name"&Qf 
<EXPLAIN><TITLE>Service Operation Name</TITLE> ' 

Detailed Description Paragraph Table - DETL (3): 

<P>The service operation name is a human readable string that ascribes 
a moniker to a service operation. It may be employed in user interfaces and 
documentation, or for other purposes.</P></EXPLAIN&gf 
oul^?o°^t*9*=^'*=^"^'^'^^^9*=*'*=^S''"'^'NG&gt:&lt:/MODE </ELEMENTTYPE&gf 
<H3>Service Operation Location&lt:/H3> <INTRO><P>The 
service location is a network resource. That is to say a 
URI.</P></INTRO> <ELEMENTTYPE 

NAME="service.operation.location"> <EXPLAIN><TITLE&gt Service 
Operation Location"</TITLE> <SYNOPSIS>A URI of a service 
operation.</SYNOPSIS&gt: &lt:P>A service operation location is a 
datatype-constrained string that locates a service operation on the Internet 
by means of a URL.</P></EXPLAIN> <MODEL&gt:&lt STRING 
?uIoI^'^f"""'^"^9*=*'*'^^'^'^''^®*9*'&'*'^MODEL> </ELEMENTTYPE&gf 
<H3>Service Operation Input Document&lt:/H3> 
&lt:INTRO><P>The input to a service operation is defined by its input 
document type. That is, the service operation is invoked when the service 
operation location receives an input document whose type corresponds to the 
document type specified by this element.</P> <P> Rather than define 
the expected input and output document types in the market participant 
document, this example provides pointers to extemally-defined BIDs This 
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allows reuse of the same BID as the input and/or output document type for 
multiple operations. In addition, it encourages parallel design and 
lmplementation.</P></INTRO> <ELEMENTTYPE 
NAME="sen/ice.operation.lnput"> &lt:EXPLAIN&gt:<TITLE>Service 
Operation lnput<n"ITLE> <SYNOPSIS>ldentifies the type of the 
service operation input document.</SYNOPSIS> <P&gt: Sen/ice location 
input is a datatype-constrained string that identifies a BID on the Internet 
by meansofa URI.</P> </EXPI_AIN> <l\/IODEL><STRING 
DATATYPE="url"></STRING></MODEL> </ELEIVIENTTYPE&gt: 
<H3>Service Operation Output Document Type</H3> 
<INTRO><P>The output of a service operation is defined by its 
output document type(s). That is, the service operation is expected to emit a 
document whose type corresponds to the document type specified by this 
element.</P></INTRO> <ELEI\/IENTTYPE 
NAME="service.operation.output"> <EXPI_AIN>&lt:TITLE>Service 
Operation Output</TITLE> <SYNOPSIS>ldentifies the type of the 
service operation output document.</SYNOPSIS> <P>Service location 
output is a datatype-constrained string that identifies a BID on the Internet 
by meansofa URI.</P> </EXPI_AIN> &lt:MODEL><STRING 
DATATYPE="url"></STRING></MODEL> </ELEMENTTYPE> 
<H3>Service Terms</H3> <INTRO><P>This is a simple 
collection of string elements, describing the temns of an 

agreement.</P>&lt:/INTRO&gt: <ELEMENTTYPE NAI\/IE="service.terms"> 
<EXPLAIN><TITLE>ServiceTerms<n"ITLE> 
<SYNOPSIS>Describes the temns of a given agreement.</SYNOPSIS> 
</EXPI_AIN> <MODEL>&lt:STRING 

DATATYPE="string"></STRING>&lt:/MODEL> &lt:/ELEMENTTYPE> 
</DTD> </SCHEMA&gt: 



Detailed Description Paragraph Table - DETL (6): 



Market Participant DTD &lt:IELEMENT business (party.name+, address.set)> 
<IATTLIST business business.number CDATA #REQUIRED <!ELEMENT party.name 
(#PCDATA)> <!ELEMENT city (#PCDATA)> <!ELEMENT internet 
(#PCDATA)> <IELEMENT country (#PCDATA)> <!ELEMENT state 
(#PCDATA)> <IELEIVIENT email (#PCDATA)> <!ELEIVIENT address.physical 
(street, city, state postcode?, country)> <!ELEMENT telephone 
(#PCDATA)> <!ELEMENT person (party.name+, address.set)> <!ATTLIST 
person SSN CDATA #IMPLIED > <!ELEMENT fax (#PCDATA)> <!ELEMENT 
street (#PCDATA)&gt: <!ELEIVIENT address.set (address.physical, telephone*, 
fax*, email*, internet*)> <IELEMENT postcode (#PCDATA)> 
<!ELEMENT market.participant (business .vertline. person)> Service DTD 
<!ELEMENT sen/ice.location (#PCDATA)> <!ELEMENT service.temis 
(#PCDATA)> <IELEMENT service.operation.name (#PCDATA)&gt: <IELEMENT 
service.operation (service.operation.name, service.operation.loc ation, 
sen/ice.operation.input, service.operation. output)> <!ELEMENT service 
(service.name, service.location, service.operation+, service.terms) > 
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<!ELEMENT service.operation.input (#PCDATA)> <!ELEMENT 
service.operation.location (#PCDATA)> <!ELEMENT service.name 
(#PCDATA)> <!ELEMENT service.set (service+)> <!ELEMENT 
service.operation.output (#PCDATA)> 



Detailed Description Paragraph Table - DETL (7): 



<?xm! version="1.0"?> <!-rorder.xml Version: 1.0 -> 
<!Copyright 1998 Veo Systems, Inc. -> <!DOCTYPE 
transaction.description SYSTEM "urn:x-veosystems:dtd:cbl:transac t: I.O.> 
<transaction.descriptlon transaction .type="order"> <meta&gt: 
<urn?urn:x-veosystems:doc:00023 </urn> &lt:thread.id 
party.assigned.by="reqorg">FRT876 </thread.id> </meta&gf 
<issuer.pointer> <xll.locator urllink="reqorg.xml">Customer 
Pointer </xll.locator> </issuer.pointer> 

<counterparty.pointer&gt: <xll.locator urllink="compu.xml"&gt: Cataloq 
entry owner pointer </xll.!ocator> &!t:/counterparty.pointer> 
<exchange.description> <line.item> <product.instance> 
<product.descriptlon.pointer> <xll.!ocator 
urllink="cthink.xml"&gt: Catatoaue Entry Pointer <xll.locator> 
</product.description.pointer&gt: <product.specifics> 
<info.description.set> <info.description> <xml.descriptor> 
<doctype> <dtd system.id="urn:x-veosystems:dtd:cbl:gprod-1 07&gt- 
<doctype> <xml.descriptor.details> 
<xll.xptr.frag>DESCENDANT(ALL. os)STRING("Windows 95") 
</xll.xptr.frag> 

</xll.xptr.frag>DECENDANT(ALL.p.speed)STRING("200") 
</xll.xptr.frag> 

</xll.xptr.frag>DESCENDANT(ALL.hard.disk.capacity) STRING("4") 
</xll.xptr.frag> ^ ' 

</xll.xptr.frag>DESCENDANT(ALL.d.size)STRING("14.r') 
</xll.xptr.frag> </xml.descriptor.details&gt: 
</xml.descriptor> </info.description> 
</info.description.set&gt: &it;/product.specifics&gt: &lt:/quantity&gt:1 
</quantity> </product.instance> <shipment.coordinates.set&gf 
&lt:shipment.coordinates> <shipment.destination> <address set&gt- 
<address.named&gt:SW-1 &lt:address.named> &lt:address.physical&gt' 
<building.sublocation>208C&it;/buildlng.sublocation> 
<location.in.street>123 </location.in. street> 
<street>Frontage Rd. </street&gt: &lt:city&gt:Beltway </city> 
<country.subentity.us countiy.subentity.us.name="MD7&gt- 
<postcode>20000 

Detailed Description Paragraph Table - DETL (19): 



-^3^3 to XML <I.DOCTYPE tree SYSTEM "tree.dtd"&gt: &lt:tree source = "null" 
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pass-through = "false"> <before&gt: <vardef name = 

"attribute.def > <element source = "ATTRIBUTE" class = "NAME" type = "5" 

position = "-2"> <parse&gt: &lt:data class = "java.lang.String" 

position = "-2"/> </parse> </element> </vardef> 

<vardef name = "pcdata.def '> <element source = "PCDATA" class = 

"NAME" type = "4"position = "-2"> <parse> <data class = "999" 

type = "6" position = "-2"/> </parse> </element> 

&lt:/vardef> <vardef name = "content.def '> <element source = 

"PCDATA"> &lt:parse> &lt:data class = "999" type = "6" position = 

"-2"/> &lt:/parse> </element> &lt:/vardef&gt: &lt:vardef name = 

"ServiceSet.var"> &lt:element source = 

"com.veo.xdk.dev.schema.test.blib.ServiceSet" class = "sen/ice.set" type = "4" 
position = "-2"> <parse> <callvar name = "Service.var"> 
</parse> </element> </vardef> <vardef name = 
"PrototypeServlce.var> <element source = 
"com.veo.xdk.dev.schema.test.blib.PrototypeService" class = 
"prototype.service" type = "4" position = "-2"> <parse> <callvar 
name = "pcdata.def parms = "setSource ServiceNameToXML setGenerator 
service.name7> <callvar name = "pcdata.def parms = "setSource 
ServiceTermsToXML setGenerator service.terms"/> <callvar name = 
"pcdata.def parms = "setSource ServiceLocationToXML setGenerator 
service.location"/> <callvar name = "ServiceOperation.var"/> 
</parse> </element> </vardef> &lt:vardef name = 
"Service.var> <element source = 

"com.veo.xdk.dev.schema.test.blib.Service" class = "service" type = "8" 

position = "0"&gt: <parse> <callvar name = "pcdata.def parms = 

"setSource ServiceNameToXML setGenerator service.name"/> <callvar name 

= "pcdata.def parms = "setSource ServiceLocationToXML setGenerator 

service.location"/&gt: <callvar name = "ServiceOperation.var"> 

<callvar name = "pcdata.def parms = "setSource Sen/iceTermsToXML 

setGenerator servlce.terms"/> </parse> &lt:/element&gt: 

</vardef> <vardef name = "ServlceOperation.var"/> <element 

source = "com.veo.xdk.dev.schema.test.blib.ServiceOperation" class = 

"service.operation" type = "4" position = "-2"> <parse&gt: <callvar 

name = "pcdata.def parms = "setSource ServiceOperationNameToXM L setGenerator 

service.operation.name"/> &lt:callvar name = "pcdata.def parms = 

"setSource Sen/lceOperationLocation ToXML setGenerator 

sen/ice.operation.location"/&gt: <callvar name = "pcdata.def parms = 

"setSource ServiceOperationlnputToX ML setGenerator 

service.operation.inpuf /> <callvar name = "pcdata.def pamis = 

"setSource ServlceOperationOutputTo XML setGenerator 

service.operation.output"/> &lt:/parse> </element> 

</vardef> </before> <parse> <callvar name = 

"ServiceSet.var"/> <callvar name = "PrototypeServlce.var"/> 

<callvar name = "Servlce.var"/> <callvar name = 

"ServiceOperation.var-Y> </parse&gt: &lt:/tree> XML to Java 

<!DOCTYPE tree SYSTEM "tree.dtd"&gt: &lt:tree source = "null" pass-through 

= "false"> <before&gt: &lt:vardef name = "business. var"> 

<element source = "business" class = 
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"com.veo.xdk.dev.schema.test.blib.Business" type = "7" setter = 
"setBusiness"> <before> <onattribute name = "business.number"> 
<actions> <callmeth name = "businessNumberFromXML"> <pamis&gt- 
<getattr name = "business.number"/&gt: </pams> </callmeth&gf 
&lt:/actions> &lt:/onattribute> <before> &lt:parse&gt: 
<callvar name = "party.name.var" parms = "setPosition -17> <callvar 
name = "address.set.var/> </parse> </element> 
</vardef> <vardef name = "party.name.var"> <element source = 
"party.name" setter = "partyNameFromXML" position = class = 
"java.lang.String"> <parse> <data class = "java.lang.String" 
position = "0'7> </parse> </element&gt: </vardef> 
<vardef name = "city.var"> <element source = "city" setter = 
"cityFromXML" position = "-1" class = "java.lang.String"> <parse&gt- 
<data class = "java.lang.String" position = "0"/> &lt:/paree> 
</element> &lt:/vardef> <vardef name = "Internet. var"> 
<element source = " internet " setter = "intemetPromXML" position = 
class = "java.lang.String"> <parse> <data class = 
"java.lang.String" position = "07> </parse> </element> 
</vardef> <vardef name = "country. var"> <element source = 
"country" setter = "countryFromXML" position = "1" class = 
"java.lang.String"> <parse&gt: <data class = "java.lang.String" 
position = "07> /&lt:parse> 

Other Reference Publication - OREF (1): 

"W3C: Extensible Markup Language (XML) 1.0-W3C Recommendation Feb 10 
1998", http://www.w3.org/TR/1998/REC-xml-19980210, Printed from Internet Feb' 
17. 1998. pp. 1-37. 



2/27/05, EAST Version: 2.0.1.4 



